Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

split explicit corrections #16

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

split explicit corrections #16

wants to merge 5 commits into from

Conversation

mark-petersen
Copy link

@mark-petersen mark-petersen commented Apr 19, 2022 •
edited
Loading

This PR, transplanted from MPAS-Dev/MPAS-Model#728, tests the following issues in the Split Explicit time-stepping routine:

  1. Re-split baroclinic/barotropic velocity at the beginning of every time step.
    Previously, we carried the barotropic velocity from one timestep to the next, rather than re-splitting.
  2. Set the new barotropic velocity to ubar = F/H
    Currently, the new barotropic velocity is computed from the average over the subcycles.
  3. Subtract barotropic average of baroclinic velocity from the new momentum velocity:
    u = ubar + u' - btrAvg( u' )
    Previously, u = ubar + u' and btrAvg( u' ) was not subtracted.
  4. Set transport velocity (normalTransportVelocity) to:
    uTr = F/H + u' - btrAvg( u' ) + uBolus - btrAvg( uBolus )
    This is a simplification to remove the velocity correction term. Algebraically it is identical to before.

here:
F is the accumulated barotropic flux
H is the total column depth, including SSH, from the last time known.
u' is the baroclinic velocity from stage 1
ubar is the barotropic velocity

Previously, normalVelocity could deviate from normalTransportVelocity and become noisy. Since normalVelocity does not feed back into the pressure gradient, there was no control on this noise. The previous version also used the velocityCorrection variable, which was extremely noisy, but also misleading, because it was really just the difference between normalVelocity and normalTransportVelocity. There is no need for velocityCorrection when the velocities are built directly, as shown above.

@dengwirda
Copy link
Collaborator

@mark-petersen, as part of revisiting the mode-split integrators here, I'm also interested in how our approach compares with some of the current "better" algorithms:

Also, just to migrate some of our slack conversation yesterday:

  • For testing, I think we should do detailed RK4 vs split-explicit comparisons in a full ocn spin-up, with as many output variables active as possible. Though it will be expensive (for RK4), I think a comparison after >= 1 yr would be best, to allow enough spin-up for baroclinic signals to develop.
  • Since the changes look to impact normalVelocity (and normalTransportVelocity) in general, I'm still not clear on how the differences in model behaviour are restricted to vertVelocityTop alone, since quite a few things (kinetic-energy, rel.-vorticity, divergence, etc) are computed using the same normalVelocity in mpas_ocn_diagnostics and these things drive the momentum tendencies?

@mark-petersen mark-petersen force-pushed the mark-petersen/ocn/split-explicit-corrections branch from e9e8e97 to e919f3a Compare April 21, 2022 04:26
@dengwirda
Copy link
Collaborator

@mark-petersen I did some initial testing of ideas 1-4 above but unfortunately am not seeing the best outcomes at present:

  • I'm restarting at year 4 in a QU30km MPAS-O standalone spin-up (in which the 'standard' split-explicit was used).
  • Running 30 days of RK4 cleans up the grid-scale noise in vertVelocityTop and maintains the spun-up kinetic-energy.
  • Running 90 days of split-explicit with new 1+2 active does seem to improve the noise in vertVelocityTop, but at the expense of a precipitous reduction in kinetic-energy + circulation, so I believe this can't be quite right.
    se_new_1p2_vs_rk4
    In the 'standard' split-explicit code, I also noticed that the normalVelocityCorrection seems to be applied only to normalTransportVelocity and not normalVelocity?
    I'm not sure I currently understand this --- my current thinking is that normalVelocity and normalTransportVelocity should only differ by normalGMBolusVelocity; that is normalVelocity = normalTransportVelocity when GM = .false.?

@mark-petersen mark-petersen force-pushed the mark-petersen/ocn/split-explicit-corrections branch from 2265918 to 1a151a5 Compare October 31, 2022 15:25
xylar pushed a commit that referenced this pull request Nov 8, 2023
@eclare108213
Merge pull request #16 from eclare108213/update_icepack_2
79526bd 
updating Icepack to hash 6ca316f, adding wlat for FSD, updating colpkg
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@mark-petersen @dengwirda